Currently, the most common way of designing and constructing an application is to analyze the functional requirements of the application and to break down the development of the application into a number of manageable functional components. Each of these components is coded in such a way to interface with another component in order to generate the final application. A disadvantage of building applications in this way is that there is no form of reuse as one component is often built to interface with a specific component and not other components. This is inefficient because a developer has to re-write code each time a particular component is built in order for it to communicate with and interface to a specific component.
A more effective method of designing and building these components is to change the basic premise that a component can only work with another specific component. Hence, components are now coded with a set of rules that present an interface to any other component. An interface defines what information is passed to and from one component to another. An example of this is where a component will only allow a customer number to be sent to it and will only send back an account balance. Only by following these rules can one component send or receive information from another component. By hiding what the component actually does behind these rules and only allowing communication to it by following these rules, components can be reused.
The above concepts define a Service Orientated Architecture (SOA). By providing the right type of software infrastructure it is now possible to reuse any component as part of any number of applications. Therefore components can be thought of in terms of service components, i.e., a component providing a service to other components. Service components are now inherently reusable, i.e., one service component can be used as part of several services. Hence, a software developer only has to write the service component once and after that the service component can be reused as appropriate in any number of other applications.
For example, service ‘A’ comprises four service components, namely service component one, service component two, service component three, and service component four. If each service component represents one unit of work to develop, service ‘A’ will take four units of work to develop. However, service ‘B’ is made up of service component one, service component two, service component five and service component six. Therefore, as service component one and service component two can be reused from service ‘A’; service ‘B’ will take just two units of work to develop instead of four.
However, there is a need in the art to develop an approach to understanding reuse value of a service component in a service orientated architecture.